Co to zas bylo za zvíře, co spáchalo tenhle paskvil?! Pipelining že je odpověď na nedostatečnou rychlost šíření světla? Sakra, když už tomu autor vůbec nerozumí, tak ať to někde všecko prostě opíše, proč to musí ještě sežvýkávat svým rozoumkem? Nepsal tenhle člověk před časem ty zrůdnosti o grafice ve hrách, kde si vymýšlel nekonečné odrazy fotonů?

Elektrony se pohybuji v řádech 10 na 5tou m­/s pri pokojové teplotě

Zdravim,

Chtěl jsem se zeptat zda­-li internetový magazín světhardware spolupracuje s tištěným magazínem CHIP od Vogel publishing. Ptáme se, jelikož jsem předplatitel CHIPu a prvidelný čtenář světahardware a v srpnovém číslu CHIPU jsem našel stejný článek ­(ne doslovně­) se stejnými obrázky ... Navíc jsem v také našel v srpnovém číslu CHIPu recenzi na stejnou sestavu lynx, kterou recenzoval p. Igor Viduna. Ptám se proto, jestli má cenu přeplácet CHIP, když to samé si můžu zadarmo přečíst na internetu :­-)

Odstavec o pipeline neni spravne. Pipeline nevznikla kvuli konecne rychlosti signalu ­(ackoliv bych veril, ze dnes to CPU potrebuji take­). Duvodem vzniku je hlavne zvyseni vykonu CPU. Vykonavani intrukce se totiz deje v nekolika krocich, napr. FETCH, DECODE, EXECUTE, STORE, v pripade neRISCovych procesoru dokonce jeste kazda z techto operaci ­(hlavne EXECUTE­) muze obsahovat dalsi kroky. Kazdy krok odpovida jednomu taktu procesoru, potom napr. vyse uvedena intrukce by trvala 4 hodinove cykly. Vtip je v tom, ze pokud je intrukce treba ve stavu DECODE, pak cast CPU odpovedna za FETCH nedela nic. Proto pipeline rozkouskuje vykonavani instrukce a procesor zpracovava nekolik instrukci najednou v ruznych fazich rozpracovani. V idealnim pripade, tedy pokud jsou na sobe intrukce nezavisle, trva ve vysledku vykonani instrukce 1 cyklus. Krome pocatecni faze, kdy je potreba pipeline naplnit, je tedy narust vykonu ctyrnasobny, aniz by se jakkoliv zvysovala frekvence!!! Cim vic kroku ma zpracovani instrukce a tudiz moznych stupnu pipeline, tim je narust vyssi. Dokonce i v nejhorsim pripade, kdy jsou intrukce na sobe zavisle, nebude vykon nizsi nez v CPU bez pipeline.

Dik za clanek. Je zjevne, ze evolucni vyvoj CPU ­(Moore a pod.­) miri ke svym limitum a musi prijit reolucni zmena. Muzete mi nkdo vysvetlit, proc se dosud neuplatnily CPU s masivne paralelni architekturou? Zatim se objevily pouze naznaky paralelismu ­(MMX, SSE, Intelovsky marketingem nafoyukly hyperthreading­). Vzdyt dnesni ­"killer applications­" ­(3D hry, ­(de­)kodovani videa, rozpoznavani reci a obrazu­) jsou pro paraleni zpracovani vhodne, na rozdil textovych editoru ap­). Tak proc tady jeste neni CPU treba s 64 jednoduchymi a rychlymi ALU jednotkami? Je to vse jen problem stavajicicho SW a kompilatoru?

Pokud je naitvnim kodem pro Itanium instrukcni sada IA32, ktera se dale dekoduje na RISC mikroinstrukce ­(neni to blbost?­), pak jak muze mit kompilator softwaru vliv na pararelismus v RISC jadre? Napdaji me dve veci, 1. bud je sled nativnich Instrukci IA32 tak kompilatorem upraven, ze tok mikroinstrukci z dekoderu rovnou vyhovuje onomu pararelismu na nizsi urovni nebo 2. je kompilatorem vytvoren RISC kod, v podstate rovnou nativni mikroinstrukcni RISC kod a ten se rovnou mimo dekoder sype do vypocetnich jednotek a pak kompilator primo takto ovlinuje vytvorenym kodem vyuziti pararelismu v Itaniu. To by pak Ale bylo Itanium ciste RISC procak ne? A nebo je moje moznost 2 blbost...

No zbytky z minulosti se jeste projevuji, takze i za pomoci informaci z netu zatim tvym informacim rozumim, navrhuji, az se dikuse trochu rozroste tyto nektere otazky a odpovedi dat pred zaver serie :­). Ale mam problemek s tvym termine, scheduler rozhazuje ony mikroinstrukce do jednotek kde je urceno jejich zpracovani? Teda u Itania schedle jednotky nejsou, u P4 jsou mezi trace cache ­(cache s mikroinstrukcemi­) a vlastnimi vypocetnimi jenotkami, u AMD je schedulinge mezi dekoderem a vypocetnimi jednotkami?

S tema nakresam deju v pipelajnech versus schema procesoru si teda musim dat pozor Intel i AMD je zacinaj teda kazdej jinak, trumberove..., no i kdyz to asi taky vliv tech vnitrnich rozdilu. A nuzu rict, ze tohle dost lidi, i me, mate, ted uz teda ne, ale stejne by to chtelo nekde popsat.

Co je druha faze dekodovani? Je to jeste soucast dekodovani instrukci na mikroinstrukce, nebo uz je to neco kolem scheduleru ­(jakysi rozhodnuti kam se so nahazi­), pripadne jeste neco tesne pred vlastni vypocetni operaci?

Proc Intel zduraznuje ze ma napr. jeho P4 12 kB cahce na mikroops, to jsou dle me ty mikroinstrukce za dekoderem, a AMD o nicem takovem nemluvi? Takhle me to pripada jako kdyby AMD melo L1 cache na instrukce pred dekoderem a za nim nic a rovnou sup s tim do vypocetnich jednotek, zatimco P4 si dopredu nasysli mikroinstrukce v L1 cachy za dekoderem? Nekamenujte me, byl jsem linej se podivat na netu na schema obou procaku ­(p4 versus AMD32, AMD64­). Jen mi to nejak nestimuje. Na Data ma L1 jak AMD tak IP4 oddelenou od L1 na iinstrukce , to vim. Jen mi to pripada, ze P4 ma L1 na mikroinstrukce a AMD na x86 instrukvce, stejne jako Itanium, viz obrazek v clanku. Teda predpokladam, ze to dekodovani v pipelajne ­(viz obrazky­) je jeste na nizsi urovni, ale to mi nejak nesedi, mam z toho gulas asi ty nakresy jsou na schematicky rozdilne urovni a ja jsem z toho ted jelen. Pomoooc :­-­(.

Předvídání skoků ­(zde spíše ­"předvídání výsledků­") opravdu není žádná ­"černá magie­", algoritmus není nijak složitý a je přesně popsán v dokumentech, které jsou jak u Intelu, tak u AMD ke stažení.

Ja si nemuzu pomoct, ale tohle me zajima ­- zbytky konicka z hluboke minulosti ­- stourani ve strijaku :­). Rozhodne je to mnohem zajimavejsi nez diskuse typu ATI ruleeez, Intel ruulleeeez apod. blbiny...

Pod dnesnim terminem upgrade microcodu procesoru prostrednictvim biosu se rozumi v podstate uprava algoritmu dekoderu instrukci na RISC mikroinstrukce v procesoru?

Jestli to tady i jinde na netu dobre chapu, tak x86 procaky rozkladaji instrukce x86 na mikroinstrukce az od dob pentia pro? Ja jsem naposled programoval v assembleru na ZX spectru, tak me to zajima. Driv mnou vytvorene instrukce pres assembler procak primo nativne vykonaval. Tkahle to tedy fungovalo az do Pentia MMX, pak uz bylo predelano na RISC jadro. Takze od pentia pro je mozne pres update biosu menit microcod procesoru a tim i jeho chovani v urcitych aplikacich, takze ho jaksi do urcite miry optimalizovat ­(ovlivneno samozrejme vnitrni architekturou­) na urcity sled instrukci a tak i aplikaci? Itanium emuluje x86 taky pres rozklad na mikroinstrukce nebo ma nad procesorem nejakej vyssi dekoder? Samozrejme, protoze jeho architektura pocitala od zacatku s jinou instrukcni sadou, tak to neni moc efektivni, zatimco u x86 vyrobci procaku tak nejak maji pred sebou x86 instrukcni sadu a optimalizuji dekoder na mikroisntruce + RISC jadro pod nim tak nejak spolu ­(obcas si nejake nove instrukce primysli, ktere sedi prave tomu jejich RISC jadru po dekoderem lepe ­- SSE2 apod.­). Jsou moje zavery spravne nebo uz kecam z hladu?

Teda Eagle, jeste jsem to nedocet, ale rychle si oprav to o tech elektronech a 300 000 km­/s, toto s tim vakuem lze rici jen o elektrickem, gravitacnim, magnetickem aj. poli. O elektronech to mozna nekdy v budoucnu muze platit az bude vytvorena kvantova teorie gravitace ­(tzv. teorie vseho­), ale i tak by to byl spis nejakej figl. 1. elektrony se pohybuji v materialu relativne dost pomalu ­(zvhledem k pouzivanemu napeti, snad jen mm­/s ­-milimetry za sekundu ­- clovek znaly si muze zrychleni elektronu pri 1,5 V spocitat pri vzadelostech v procesoru, ale to si ted nejsem jistej­), pouze el. pole se siri nejakejch o neco malo nez 300 000 km­/s ve vakuu, hnidopich by rekl 299 792.458 km­/s ;­-­). V soucasnosti nelze elektrony na 300 000 km­/s urychlit ani za boha, no dobre prilis se drzim textu.... Ale i tak urychleni elektronu na , rekneme,298000 km­/s ;­-­) pouze elektrickym polem by si vyzadalo slusne velkej rozdil elektrickeho potencialu, nebo dost slouhou drahu ­(vynechavam cyklotrony­). Honem dostudovat a opravit :­-­).

Jen malý detail ­- elektrony se nepohybují rychlostí světla, tou rychlostí se pohybuje elektromagnetické pole. Elektrony samy se při běžných proudech pohybují rychlostmi o mnoho nižšími, řádově jen několik milimetrů za sekundu.

už se těším na zítra. :­-)